Skip to content

feat(minidump): Add sentry-minidump integration - #1315

Merged
szokeasaurusrex merged 16 commits into
getsentry:masterfrom
timfish:feat/minidump-integration
Sep 17, 2026
Merged

szokeasaurusrex merged 16 commits into
getsentry:masterfrom
timfish:feat/minidump-integration

Conversation

@timfish

@timfish timfish commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Adds a new sentry-minidump crate that captures native crashes as minidumps in a separate process and sends them to Sentry as attachments. Enable it with the minidump feature on sentry. Linux, macOS and Windows only.

The code is ported from the standalone sentry-rust-minidump crate.

How it works

The integration re-executes the current binary as a crash reporter process. The app process spawns the reporter and connects to it; the reporter attaches a native crash handler and waits. On a crash it writes a minidump, attaches it to a Fatal event, and uploads it. Scope does not cross the process boundary on its own. To give the crash event context (user, tags, extra, breadcrumbs), the app sends updates to the reporter explicitly through methods on the integration; each call is forwarded over a socket and applied to the reporter's scope.

Difference from sentry-rust-minidump

In sentry-rust-minidump the process model is explicit: you call init(&client), which re-executes the binary, and you then have to pass the client in by hand, keep the returned Handle alive for the life of the program (or leak() it), and know that everything before init runs in both processes.

Here the process work moves inside Integration::setup, which runs inside Client::with_options before sentry::init binds the client to the hub. That removes most of the ceremony:

  • In the app process, setup spawns the reporter and keeps the handle inside the integration, which the client owns for the life of the process. No Handle, no leak(), no client to pass in.
  • In the reporter process, setup never returns. It builds its own client from the cloned ClientOptions, runs the minidump server loop, and exits. sentry::init is the last line of main that runs there.

Scope sync is still manual, reached via sentry::with_integration instead of a method on a Handle. inherit_args now defaults to true since I suspect this will be more useful to most without causing pain for others.

The one caveat is inherent to re-executing the binary: code before sentry::init still runs in both processes. is_crash_reporter_process() stays public so apps can gate on that.

Resolves #1316

@timfish
timfish requested a review from a team as a code owner September 11, 2026 12:50
@sdk-maintainer-bot

This comment was marked as resolved.

Comment thread sentry-minidump/src/lib.rs Outdated

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Comment thread sentry-minidump/src/lib.rs Outdated

@szokeasaurusrex szokeasaurusrex left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the most part, this looks good, but I left a couple suggestions I think we should implement before merging.

I tested it out locally and the crashes are showing up nicely in the UI.

Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/src/lib.rs
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/tests/e2e.rs Outdated
Comment thread sentry-minidump/Cargo.toml Outdated
Comment thread sentry-minidump/README.md

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

h: We generate these README.md files with cargo readme in the version-bumping script, using this command:

cargo readme --template ../README.tpl --output README.md

The files are generated from the crate-level documentation in src/lib.rs. It seems that this README contains some information not included in src/lib.rs, so you should move that information into src/lib.rs so that the README survives regeneration.

Comment thread sentry-minidump/src/lib.rs Outdated
@codecov

codecov Bot commented Sep 14, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 222 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.14%. Comparing base (a57b91c) to head (4973465).
⚠️ Report is 181 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1315      +/-   ##
==========================================
+ Coverage   73.81%   74.14%   +0.32%     
==========================================
  Files          64       79      +15     
  Lines        7538     9950    +2412     
==========================================
+ Hits         5564     7377    +1813     
- Misses       1974     2573     +599     

@timfish

timfish commented Sep 14, 2026

Copy link
Copy Markdown
Contributor Author

@szokeasaurusrex do you think we should set the default process name as sentry crash reporter, crash reporter or similar?

@szokeasaurusrex

szokeasaurusrex commented Sep 14, 2026

Copy link
Copy Markdown
Member

@szokeasaurusrex do you think we should set the default process name as sentry crash reporter, crash reporter or similar?

Yes, I think that's a good idea, but I'd also include some indication that the process is part of the Rust SDK.

I think something like "Sentry Rust SDK Crash Reporter" or "Crash Reporter (Sentry Rust SDK)" could work well.

@szokeasaurusrex szokeasaurusrex left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you addressed my previous feedback 🙏

I identified a couple more small items but lgtm in general; please ping me when this is ready to be merged

Comment thread sentry-minidump/examples/app.rs
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/src/lib.rs Outdated
@szokeasaurusrex

Copy link
Copy Markdown
Member

@timfish if I understand correctly, after this change is released, the existing sentry-rust-minidump crate will continue to exist separately, and this will be released as a new sentry-minidump crate?

The one thing I am not sure about is whether Craft will be able to create a new crate when releasing, or if it will error because the crate does not exist yet. I haven't released a new crate at Sentry before so this may be worth looking into

@timfish

timfish commented Sep 16, 2026

Copy link
Copy Markdown
Contributor Author

the existing sentry-rust-minidump crate will continue to exist separately, and this will be released as a new sentry-minidump crate?

At some point I will publish a release of sentry-rust-minidump with deprecation and readme notices pointing to the new officially supported integration.

sentry-minidump using the integration API makes sentry-rust-minidump redundant!

timfish and others added 2 commits September 16, 2026 02:05
Co-authored-by: Daniel Szoke <7881302+szokeasaurusrex@users.noreply.github.com>
@szokeasaurusrex
szokeasaurusrex enabled auto-merge (squash) September 16, 2026 12:02
Comment thread sentry-minidump/src/lib.rs Outdated
Comment thread sentry-minidump/tests/e2e.rs Outdated
Comment thread sentry-minidump/src/lib.rs Outdated
Make some improvements to the `sentry-minidump` e2e test that will make the test more reliable and faster:

- Allow the OS to assign an available port for the test rather than hardcoding port `8123` (or another fixed port), which causes the test to fail when that port is occupied
- Add a timeout for the child process to ensure the test does not get stuck waiting forever if the child process does not exit
- Lower existing timeouts and delays to make the test run faster
cursor[bot]

This comment was marked as resolved.

Comment on lines +467 to +477
return;
}
match self.build_child().spawn() {
Ok(handle) => {
let _ = self.handle.set(handle);
}
Err(err) => {
sentry_debug!("could not start crash reporter: {err}");
}
}
});

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: A panic within the setup function's call_once block can poison a static Once guard, causing subsequent sentry::init calls to panic immediately.
Severity: LOW

Suggested Fix

To prevent the Once from being poisoned, wrap the code inside the call_once closure with std::panic::catch_unwind. This will catch any panics, allowing the program to handle the error gracefully without poisoning the static Once guard and preventing subsequent initializations from crashing.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry-minidump/src/lib.rs#L456-L477

Potential issue: The `setup` function uses a static `std::sync::Once` to ensure its
initialization logic runs only once. If a panic occurs within the closure passed to
`SETUP.call_once`, for instance, if an integration's `setup()` method panics during the
creation of the crash reporter client, the `Once` object becomes poisoned. Any
subsequent attempt to initialize the client by calling `sentry::init` will trigger
`setup` again. The subsequent call to `SETUP.call_once` will then immediately panic
because the `Once` is poisoned, leading to a crash. While this requires a second
`sentry::init` call after a panic, it represents a potential unhandled crash condition.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok, because we would have already panicked, and multiple initializations are rare

@szokeasaurusrex
szokeasaurusrex merged commit cbed0fa into getsentry:master Sep 17, 2026
28 checks passed
@timfish
timfish deleted the feat/minidump-integration branch September 17, 2026 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add sentry-minidump integration to Rust SDK

2 participants